Attribute DXL befavior in Baselines

DOORS version is 9.4.

I have an Attribute DXL that takes it's values from another module following a link.

So when the master module updates, all slave modules will get the updated value for this attribute.

However, all baselines of those said slave modules have the updated value.

I thought but not 100% sure that this behavior was not in previous versions of DOORS.

The code is something like this (without the fluf):

Link l
for l in all(obj->"somelinkmodule") do {
target_object = target l
set(obj.attrDXLName, target_object.attrDXLName)
}
In my mind this should never happen as the baseline is read only, so therefore the code set(xx, yy) should always fail when the baseline is accessed.
I don't have access to an old version of DOORS but if any one can check I would appresiate.

Also another behavior in 9.4 is that DXL attributes don't calculate if theyir values were "", they only calculate when Refresh DXL attribute is selected (or on module open). Previously attribute dxl were updated right away if their initial value was empty. But this is beside the point here.
ostanescu - Wed Feb 20 11:00:44 EST 2013

Re: Attribute DXL befavior in Baselines
Mathias Mamsch - Wed Feb 20 12:51:36 EST 2013

Baselines never stored the value of attribute DXL. The baseline only stores the DXL code of the attribute DXL and if that for example contains an include, and you change the include after the baseline, then you can change the values in the baselines too.

That is a known issue and workarounds mostly deal with copying DXL attribute values to an attribute before actually baselining the module.

I do not get your description of the new behaviour of attribute DXL, but an attribute DXL should calculate as soon as you show it. If you press F5 or choose refresh DXL attributes they will recalculate. I do not think that behaviour has changed since DOORS 8.

Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Re: Attribute DXL befavior in Baselines
ostanescu - Wed Feb 20 13:26:26 EST 2013

Suppose you have 2 attributes x and y, and then define dxl attr z = x + y. Add all into the current view.
Then fill in x, fill in y, in previous versions of DOORS < 9.2, z would display the sum right away, now is more consistent with the documentation and you would have to select Refresh DXL attribute to show sum, or close/reopen the module.

In regards with the main problem, the fact that some DXL attribute can change in a baseline is a big issue and defies the notion of baseline.

So if DXL attributes have no container then is a mere Layout.

So the solution is to make a companion attribtue that the DXL attribute saves value in when calculating its own.
Then its code becomes:

if(isBaseline module obj) [
set(obj.attrDXLNAme, probeAttr_(obj, attrDXLName "x"))
}
else {
val = go to master module

set(obj.(attrDXLName "x"), val)
set(obj.attrDXLName, val)

}

Re: Attribute DXL befavior in Baselines
llandale - Wed Feb 20 13:51:10 EST 2013

Yes, it appears they slightly changed the when attr-DXL (and I presume Layouts) changes; I think in v9. I didn't spend much time on it, but suspect that null-Attr-DXL is not recalculated when displayed, it is recalculated the 1st time it is requested after it has been erased.

These two Att-DXL used to be the same, but now they are different:

if (there are not enough inputs) then obj.AttrDXLName = ""
if (there are not enough inputs) then halt

The second one will cause constant recalculation even in v9; the 1st no longer does.

I think.

I see no changes in the method when there is a calculated value.

<<<<<<<<<<<<<<<<<<<<

As for your problem where the Inputs are a function of Links, then you have a bigger problem vis-a-vis "versioned" links; since you care about the links that existed at the time of the baseline and NOT based on those that exist now. Sadly, I know nothing about this sort of linking.

All-in-All it would behoove us to save the values of Attr-DXL before baselining; then all these issues disappear. Maybe I should write it; perhaps this would work:

For each attr-DXL in each module
- Access all the obj-attr values
- copy the definition, named <oldName>_Saved
- change the properties of the original such that it is no longer an Attr-DXL.
save
baseline.
for each "_Saved" attr-DXL in the module
- get it's DXL.
- change the properties of the corresponding Attr-DXL, and set it's DXL
- delete the _Saved version

<<<<<<<<<<<<<<<<<<<<<

set(obj.attrDXLName, target_object.attrDXLName )

This just CANNOT be write ..err.. right. Where does target_object get IT'S value? What happens when an object is linked to itself? Perhaps you mean this:

set(obj.attrDXLName, target_object.SomeOtherAttr )

Also, this value will only be a function of the LAST link visited. You want something like this:

Link l
Buffer buf = create
for l in all(obj->"somelinkmodule") do {
   target_object = target l
   if (length(buf) > 0) buf += "\n"
   buf += some information about target_object
}
obj.attrDXLName = tempStringOf(buf)
delete(buf)

-Louie

Re: Attribute DXL befavior in Baselines
ostanescu - Wed Feb 20 15:35:39 EST 2013

Loui,
You are making it more complicated than it is, the code:
set(obj.attrDXLName, target_object.attrDXLName)

works, because I made sure such attribute exists, and that one to one linking is enforced.

I have several DXL attributes, and I wanted to code in such a way that I don't need to rember attribute names.

So, for example I have:
Severity, Prob 1 and Prob 2 attributes in a master hazard module.

Then, I have many more smaller hazards product specific modules which needs not to worry about Severity and Prob 2.
But can define their own Prob 1, so Severity and Prob 2 will be those dxl attribtues with the exact same DXL code, and same types respectively.

Re: Attribute DXL befavior in Baselines
SystemAdmin - Wed Feb 20 16:26:41 EST 2013

just one more remark about links:

as you want to display the information "at the time when the baseline was created, object a had content x and linked object b of another module hat content y" --> have you considered using baseline sets instead of single baselines? These seem to exactly fit your needs -- and you do not need to remember the value of the attrDXL, since you can still recalculate the value.

Re: Attribute DXL befavior in Baselines
llandale - Wed Feb 20 16:31:06 EST 2013

ostanescu - Wed Feb 20 15:35:39 EST 2013
Loui,
You are making it more complicated than it is, the code:
set(obj.attrDXLName, target_object.attrDXLName)

works, because I made sure such attribute exists, and that one to one linking is enforced.

I think you said the Master module has non-DXL attributes; but the subordinate Hazard modules want to display the Master's values, so they have DXL-attrs with the exact same name as the non-DXL-Attrs in the Master module. I guess that would work.

I guess your link loop would also work so long as there was exactly one linked parent "Master" object for each subordinate "Hazard" object and no other relationships use that particular link module.

-Louie

Re: Attribute DXL befavior in Baselines
ostanescu - Thu Feb 21 09:51:57 EST 2013

Baseline sets is a wonderfull idea, however it is implemented half way.

The reason is that you don't know before hand which baseline should be part of the set.

For example consider a baseline set of 2 modules.
Have the first module make a baseline in the set.
Then update second module and make baseline in the set.
Then some reviewer find a mistake in the second module, which willneed to be updated.

At this point, I am hosed, because I cannot replace the second module baseline in the set.
Also I cannot make a new baseline set and add the first module existing baseline.

So, the feature needs either or both of these:
- allow a previously created baseline to be added to the set
- allow replacing a baseline from the set

Re: Attribute DXL befavior in Baselines
llandale - Thu Feb 21 11:29:22 EST 2013

ostanescu - Thu Feb 21 09:51:57 EST 2013
Baseline sets is a wonderfull idea, however it is implemented half way.

The reason is that you don't know before hand which baseline should be part of the set.

For example consider a baseline set of 2 modules.
Have the first module make a baseline in the set.
Then update second module and make baseline in the set.
Then some reviewer find a mistake in the second module, which willneed to be updated.

At this point, I am hosed, because I cannot replace the second module baseline in the set.
Also I cannot make a new baseline set and add the first module existing baseline.

So, the feature needs either or both of these:
- allow a previously created baseline to be added to the set
- allow replacing a baseline from the set

3: the "removal" of a baseline; merging the History into the Next baseline or current Module.